

The agents communicate through string-based messages containing the information that shall exchange between the agents. The agents need some way to understand each other. One way to get the agents to understand each other could be to create a standardized way to create and split up a string.

In this project the ontology has been created by a hierarchy of classes and an abstract class as the root of the tree (See \figureref{ontology-figure-ontology}).

% Write about the ontology and the abstraction of it.
% The advantages and the faults of using this.

\begin{figure}[H]
  \begin{center}
    \includegraphics[trim=0mm 0mm 0mm 0mm, clip, scale=.5]{Images/Design/Ontology.jpg}
    \caption{Ontology class diagram}
    \label{ontology-figure-ontology}
  \end{center}
\end{figure}

The AMessage (See \figureref{ontology-figure-ontology}) is an abstract class with two static methods. The one method (constructMessage) is for creating a string message to an agent. The other method (retrieveMessage) is for retrieving the message from a string. Each kind of message, the agents can understand from this ontology, is a child class of AMessage (See \figureref{ontology-figure-ontology}).

The reason to create this kind of ontology is to heighten the abstraction and standardizes the message as much to find out, what kind of message it is and where it is from. The last mentioned, which means the local name of the sender, is not needed, because it is sent along in the ACLMessage from the Jade platform. The reason is for easier debugging.

The ontology uses the agents to create the message specified by the agent. To make the messages as agile as possible the agents has their own hierarchal tree (See \sectionref{design-agents}). AMessage can only be used by Messageable agents and specialized messages, such as MeasurementMessage (See \figureref{ontology-figure-ontology}), need a Sensor agent to construct a message. 